home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 7670 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.7 KB
  1. Path: newshost.lanl.gov!tanmoy
  2. From: tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya)
  3. Newsgroups: comp.lang.c,comp.lang.c++
  4. Subject: Re: OK, so data types must be declared...
  5. Date: 24 Feb 1996 18:08:17 GMT
  6. Organization: Los Alamos National Laboratory
  7. Message-ID: <TANMOY.96Feb24110817@qcd.lanl.gov>
  8. References: <4glbau$tge@inet.up.ac.za> <4glfee$185b@inet.up.ac.za>
  9. NNTP-Posting-Host: qcd.lanl.gov
  10. Mime-Version: 1.0
  11. Content-Type: text
  12. In-reply-to: Rudolph Pienaar's message of 23 Feb 1996 22:34:54 GMT
  13.  
  14. <snip>
  15. In article <4glfee$185b@inet.up.ac.za>
  16. Rudolph Pienaar <rudolph@pangea.ee.up.ac.za> writes:
  17.  
  18. RP: Thanks for the quick feedback, James -
  19. RP: 
  20. RP: You wrote:-
  21. <snip>
  22. RP: :The only reason that you don't get the warning when the argument type is
  23. RP: :an int is because for backwards compatibility reasons, (*func)()
  24. is allowed 
  25. RP: :to be treated as (*func)(int).
  26.  
  27. This answer is wrong!!! (*func)() is _not_ (*func)(int). I explained
  28. in my other post in this thread.
  29.  
  30. RP: 
  31. RP: Of course... You're completely right. However, I purposefully
  32. didn't want to 
  33. RP: explicitly associate the passed function to any one data type.
  34.  
  35. For you to be able to _call_ the function, you need to know the data
  36. type to call it with. When you call `passed(1)', how does the compiler
  37. know what form of 1 you want to pass? char, unsigned char, signed
  38. char, short, unsigned short, int, unsigned int, long, unsigned long,
  39. float, double or long double? If you write (), the rule it uses is
  40. simple: if you write 1, it passes int, 1L, it passes long and so
  41. on. In fact anything before int in my list is passed as int or
  42. unsigned int, the exact rules are called integral promotion; and
  43. floats are pased as doubles: the rest are passed exactly as you write
  44. it. So, you see that even if you declare it (), _you_ need to know
  45. exactly what it wants. And, if you know it, most often you can declare
  46. it correctly as well. (There are exceptions when () is useful. They
  47. are rare.)
  48.  
  49. In any case, if you really want (), then the actual function cannot
  50. be prototyped with parameters of type float, or anything shorter than
  51. int or with enum.
  52.  
  53. RP: 
  54. RP: Basically I could have a function called "Matrix Dfsys_eval(Dfsysdatatype
  55. RP: *sys)" and another one called "Matrix PIsys_eval(PIsysdatatype
  56. *sys)" (where 
  57. RP: Matrix is some user defined matrix data type, likewise for the
  58. different *sys). 
  59. RP: Here, the "sys" variable is a struct that contains data specific
  60. to one or the 
  61. RP: other system, and each "eval" knows how to combine this data to generate
  62. RP: output. The integration routine was declared "Matrix RK4(Matrix
  63. (*F)())" and 
  64. RP: was called by either:
  65. RP: 
  66. RP: RK4(Dfsys_eval) or RK4(PIsys_eval)...
  67. RP: 
  68. RP: In its body, it simply called a " (*F)(&sys);" to get the returned
  69. value of any 
  70. RP: system type.
  71.  
  72. How does it get the sys? Are you guaranteed that it has the correct
  73. data type for the routine called? If you are, then your declaration is
  74. correct and everything should work fine. (Remember pointers don't get
  75. promoted when calling, so if sys is the correct type, &sys is fine in
  76. the call.)
  77.  
  78. Of course, if you want to pass a null pointer, there is no way to do
  79. it without _knowing_ the type.
  80.  
  81. RP: 
  82. RP: The only way I could think around this was to declare each eval like 
  83. RP: "Matrix Dfsys_eval(void *sys)", and making sure of being
  84. consistent throughout. 
  85. RP: Of course though, this doesn't help because the "sys" in
  86. "Dfsysdatatype *sys" 
  87. RP: contains data specific to the df system, and with void pointers
  88. this data can't 
  89. RP: be deferenced; moreover trying to dereference a void pointer also
  90. generates a 
  91. RP: host of warnings.
  92. RP: 
  93.  
  94. That way is no more safe, and is just obfuscating. If you really want
  95. to do it that way, don't dereference a void poiner. Inside the
  96. routine, declare a local variable `Dfsysdatatype realsys = sys', and
  97. use realsys instead. (It does allow you to pass a null pointer,
  98. however; and that is the only reason I comment on how to do it
  99. right. Another, and possibly slightly better, possibility is to
  100. replace the void* with a pointer to and appropriate union type. This
  101. needs a cast in the realsys declaration line however.)
  102.  
  103. RP: 
  104. RP: I hope that you could glean an inkling of what I'm getting at. Any
  105. suggestions? 
  106. RP: 
  107.  
  108. It would help if you gave a realistic short example instead of getting
  109. confused over floats etc.
  110.  
  111. Cheers
  112. Tanmoy
  113. --
  114. tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
  115. Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
  116. Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
  117. <http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
  118. internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
  119. fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]
  120.